method of reducing size of presence messages

ABSTRACT

A method in a communication network of delivering messages associated with an information exchange service. A message, to be delivered between two entities is interrogated to determining if the data content has already been delivered to the terminating entity. If the data content has not already been delivered to the second entity, the message is transmitted to the second entity unchanged, while the message is modified, so that the modified message comprises a data identifier, identifying the data content, but no data content. The modified message is then transmitted to the terminating entity, and the data identifier is cached together with the associated data content when a successful transmission of the message has been verified. The suggested versioning mechanism enables transmission of messages with a reduced size.

TECHNICAL FIELD

The present invention relates generally to a method and arrangement forreducing the size of messages, such as e.g. SIP messages, communicatedbetween a client and a server, or vice versa.

BACKGROUND

IP Multimedia Subsystem (IMS) is a technology defined by the ThirdGeneration Partnership Project (3GPP) to provide IP Multimedia servicesover mobile communication networks. The IMS makes use of the SessionInitiation Protocol (SIP) to set up and to control calls or sessionsbetween user entities or between a user entity or a client and a server.Whilst SIP was created as a user-to-user protocol, IMS allows operatorsand service providers to control user access to services and to chargeusers accordingly. The 3GPP architecture defines different types of CallSession Control Functions (CSCFs), providing services to different userentities in an IMS.

There are a number of situations where an IMS client A may want tomaintain updated information about another IMS client B, which havegiven client A access permission to do so. The Presences Service basedon the IETF SIMPLE (SIP Instant Messaging and Presence LeveragingExtensions) technology is a particular application built on top of theSIP event notification framework. This type of service allows a user tobe informed about the reachability, availability, and willingness ofcommunication of another user. The presence service may be used toindicate whether different users are online or not and whether onlineusers are idle or busy. The presence service may also give details ofcommunication means and the respective capabilities of eachcommunication means. A person who is providing presence information istypically called a presences entity, or presentity. A given presentitymay have one or more entities operating as clients, typically alsoreferred to as Presence User Agents (PUAs), which can supply updatedpresence information, i.e. a set of attributes that characterize theproperties of the presentity, such as e.g. status, capabilities and/orcommunication address to a server, providing the presence service tosubscribing users.

FIG. 1 schematically shows an exemplified scenario of a SIP presencearchitecture adapted to provide a presence service according to theprior art. In an IMS network 100, three clients 101-103, which may beany of e.g. an IMS terminal, a laptop, and/or a desktop computer, eachhave a piece of information about a presentity 104 stored locally.Different clients may hold different or identical information about thepresentity 104. An IMS terminal may e.g. hold information about theregistration status of the presentity 104, while a laptop may holdinformation as to if the presentity 104 is logged on or not. Inaddition, a client may hold richer presence information, such as e.g.whether the presentity is available for videoconferences and/or wants toreceive a voice call at present. All presentity clients 101-103 sendtheir respective pieces of information to a presences server 105, whichgathers all information and obtains a complete picture of thepresentity's 104 presence. FIG. 1 also shows two users 106,107,typically referred to as watchers, each equipped with a respectiveentity 108, 109, wherein each entity is operating as a respectivewatcher client, via which the respective user 106,107 may subscribe topresence information of a specific presentity or a number ofpresentities, specified in a list, i.e. a presentities presence list.The presence server 105 notifies all the subscribing watchers when achange has occurred in the respective presentity's presence information,i.e. when a presentity has delivered new presence information to thepresence server 105 via a SIP PUBLISH request, by delivering thepublished information to the respective one or more watchers in a SIPNOTIFY request.

In current SIMPLE based solutions it is necessary for the presenceserver to send a new notification, comprising all data or parts of thedata, i.e. partial notify, whenever a change occurs in the presencedata. Such a notification must be sent no matter if the presence datahas already been delivered to a respective watcher in a previousnotification or not.

Since many of the notifications sent from the presence server to awatcher are just toggling of one data, such as “open” or “closed” for aservice, a lot of data which has already been delivered between the twoentities is sent over the air-interface. Even in the case of partialnotifications, the size is not without significance.

In addition, repeated transmissions of identical data content requiresmore complicated functionality, rendering a costly processing, both atthe server, creating a notification, and at the watcher, having toprocess each received notification and to create a final result on thebasis of the processed content.

SUMMARY

The object of the present invention is to address at least some of theproblems outlined above. In particular it is an object of the presentinvention to provide a solution that can generally reduce the size ofsome messages transmitted in a communication network between a clientand a server, or vice versa.

These objects, along with others, may be obtained by using a method andentities according to the attached independent claims.

According to one aspect, the present invention provides a method in acommunication network of delivering messages associated with aninformation exchange service between a first entity and a second entity.Initially a message, associated with an information exchange service,comprising data content and a request for versioning is processed at thefirst entity. Versioning is defined as a selectable mechanism, adaptedto associate each version of data content of a message with a dataidentifier, identifying the respective version. The first entity theninterrogates the received message, to determine if the data content hasalready been delivered to the second entity in an earlier transmission.If it is determined that the data content has not already been deliveredto the second entity, the message will remain unchanged when transmittedto the second entity. If, however, it is found that the data content hasalready been delivered to the second entity, a modified message,comprising a data identifier but no data content, is instead transmittedto the second entity.

According to a first embodiment, the first entity is a server and thesecond entity is a client.

Typically, the first entity receives a request for an informationexchange service from the second entity, prior to executing the receivedmessage, wherein the request comprises an indication that versioning isrequired. The message may be a SIP notification, which is transmittedfrom the client to the server.

According to a second embodiment, the first entity is instead a clientand the second entity is a server. In such an embodiment the message mayinstead be a SIP publication.

The suggested determining step may comprise the step of interrogating acache of the first entity in order to determine if the respective datacontent has already been delivered to the second entity.

According to one aspect, the data identifier is inserted into themessage at the first entity.

According to another aspect, the data identifier is instead providedfrom the second entity.

A data identifier provided from the second entity may be provided to thefirst entity in a response message, the response message indicating asuccessful delivery of the message.

According to another aspect, the present invention provides a method ina communication network of handling messages associated with aninformation exchange service at a first entity, wherein messages aredelivered from a second entity to the first entity.

Initially, the first entity receives a message associated with therequested information exchange service, wherein the message comprises arequest for versioning. At the first entity it is determined if themessage, requesting for versioning, comprises data content. If it isfound that the message comprises data content, a data identifier,associated with the data content is retrieved by the first entity, andthe data content is stored together with the data identifier.

If, however, the message does not comprise any data content, the messagewill instead be provided with data content associated with a dataidentifier, wherein the data identifier is retrieved from the message.Once the respective data content has been retrieved, the message may beprocessed accordingly.

According to a first embodiment, the first entity is a client and thesecond entity is a server. In such a scenario the message may be a SIPnotification.

According to one aspect, a request for an information exchange service,indicating that versioning is required, is forwarded to the secondentity, prior to executing the receiving step mentioned above.

According to a second embodiment, the first entity is instead be aserver, while the second entity is a client. In such a case the messagemay instead be a SIP publication.

According to one aspect, the data identifier is retrieved from the firstentity, wherein the data identifier may be forwarded from the firstentity to the second entity in a response message, the response messageindicating that the message has been delivered successfully.

According to yet another aspect, the data identifier may instead beretrieved from the message, the data identifier being inserted into themessage at the second entity.

According to another aspect, the data content and the associated dataidentifier are stored in a cache of the first entity subsequent toreceiving a response message, verifying that the message has beensuccessfully delivered to the second entity, and that the data contentand the associated data have been stored at another cache of the secondentity.

According to one aspect, a first response message comprises anindication of the total capacity of the cache of said second entity.

According to another aspect, each response message may instead comprisean indication of the remaining capacity of the cache of said secondentity according to another aspect. The data identifier may be a versionnumber, a unique identity, or an Etag.

According to another aspect, a first entity for delivering messagesassociated with an information exchange service to a second entity isprovided. A processing unit is adapted to process a message, comprisingdata content and a request for versioning, associated with the requestedinformation exchange service. A versioning unit is adapted to determinewhether the data content has already been delivered to the client ornot. If it is found that the data content has not already been deliveredto the client, the message will be transmitted unchanged to the clientfrom a communication unit. If, however, it is determined that the datacontent has already been delivered to the second entity, a modifiedmessage will instead be transmitted to the client, wherein the modifiedmessage will comprise a data identifier but no data content.

According to a first embodiment, the first entity is a server, while thesecond entity is a client.

According to one aspect, the communication unit may also comprise areceiver for receiving a request for an information exchange servicefrom the second entity, the request indicating that versioning isrequired.

According to yet another aspect, the versioning unit may be adapted todetermine if the data content has already been delivered to the firstentity or not, by interrogating a cache.

According to a second embodiment, the first entity is instead a client,while the second entity is a server.

According to another aspect, a first entity of handling messagesassociated with an information exchange service is provided, whereinmessages are received from a second entity. The first entity comprises acommunication unit for receiving a message from the second entity, themessage comprising a request for versioning. The entity also comprises aversioning unit for determining if the message comprises data content.The versioning unit is adapted to retrieve a data identifier associatedwith the data content and to cache the data content together with theassociated data identifier if the message comprises data content. If,however, the message does not comprise any data content, the versioningunit is adapted to provide the message with stored data content, afterhaving retrieved the associated data identifier from the message. Thefirst entity also comprises a processing unit for processing themessage.

According to one embodiment, the first entity is a server and the secondentity is a client,

According to one aspect, the communication unit of the first entity mayalso comprise a transmitter for forwarding a request for an informationexchange service, indicating that versioning is required, to the secondentity.

According to yet another aspect, the versioning unit is connected to acache, wherein the versioning unit is adapted to cache data content andan associated data identifier in response to a successfully delivered orreceived message.

According to a second embodiment, the first entity is instead a client,while the second entity is a server.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by means ofexemplary embodiments and with reference to the accompanying drawings,in which:

FIG. 1 is a basic overview of a SIP Presence architecture, according tothe prior art.

FIG. 2 is a schematic flow diagram of a presence publication between aclient and a server, according to one embodiment.

FIG. 3 is a schematic flow diagram of a presence publication between aclient and a server, according to another embodiment.

FIG. 4 is a schematic flow diagram of a presence notification between aserver and a client, according to one embodiment.

FIG. 5 is a schematic illustration of a caching of presence data,according to one embodiment.

FIG. 6 is a schematic illustration of a client adapted to provideupdated data content to a server, according to one embodiment.

FIG. 7 is a schematic illustration of a server adapted to manage updateddata content, according to one embodiment.

FIG. 8 is a schematic illustration of a client adapted to handlereceived updated data content, according to one embodiment.

DETAILED DESCRIPTION

Typically for an IMS service, such as e.g. a presence service, a largeamount of data is delivered to entities that has already receivedidentical data content earlier, i.e. in an earlier request, such as apublication or a notification. The scope of this document is to presenta mechanism which allows a transmitting entity to avoid transmittingdata content, e.g. presence information, from a transmitting entity to areceiving entity, if the same information has already been deliveredfrom the transmitting entity to the receiving entity at a previousstage.

Since many notifications that are sent from a presence server, managinga presence service, are carrying the same presence information as anearlier sent notification, it would heavily reduce the notification sizeif it would be possible to point out to the presence server whatpresence information that is presently valid for the presentity. Alsofor the communication between a presentity and the presence server acorresponding mechanism would be desirable in order to reduce the sizeof at least some of the publications.

A mechanism addressing the problems mentioned above may be achieved byincluding a data identifier, carrying e.g. an Etag, version number or aunique identifier, into a SIP message, such as e.g. a notification or apublication. Whenever a new message is to be transmitted to the sameserver or client and the data content to be forwarded via the SIPmessage is found to be identical to data content sent in an earlier SIPmessage after having interrogated a cache at the transmitting end, thenew message will only include the data identifier, thereby avoiding totransmit the already delivered data content once again. This means thatthe transmitting entity will have to keep track of the data content thathas been delivered from the entity in earlier messages, as well as thedata identifier, associated with the respective data content.

In order to get a more clearly understanding of the suggested versioningmechanism, it will now be exemplified in the context of executing apresence service, as illustrated with reference to FIGS. 2-4. FIGS. 2and 3 illustrates how versioning may be executed between a client,operating as a presentity, providing updated publications to a server,which in this case is a presentity server, according to two alternativeembodiments. FIG. 4, illustrates a way of realising a correspondingversioning mechanism, operable between a server, providing notificationsto one or more clients, and a client, operating as a watcher, receivingnotifications from the server.

For simplicity reasons, all examples in this document are limited todescribing versioning executed between two entities, i.e. between aclient and a server, such as, e.g. a presentity and a presence server,or between a presence server and a watcher. It is, however, to beunderstood that the described versioning mechanism may be applicablealso between a number of entities involved in the execution of aservice, wherein versioning may be applicable all the way from apresentity, to a presence server and also of a terminating watcher. Itis also to be understood that the described versioning mechanism is notlimited to handling only delivery of presence service information, butany type of service information delivery. In particular, versioningaccording to any of the described embodiments will also be applicable inother implementations where it is required to reduce the transmission ofredundant data content, or more specifically, the amount of data contentthat has to be transmitted between interacting entities.

FIG. 2 illustrates an exemplified signalling scenario, relevant for theexecution of publishing associated with a presence service, i.e.signalling between a client 200, operating as a presentity, providingpublications to a server, and a server 201, operating as a presentityserver. The embodiment described with reference to FIG. 2 is one way ofproviding versioning by using the already existing Etag, i.e. for usingthe Etag also for the purpose of identifying different versions oftransmitted presence information.

A client 200, having relevant presence information, i.e. data content,here identified as D1, to be deliver to a server 201 may enablingversioning if such a mechanism is supported by both entities.Publications are typically delivered between entities as messages,provided as publication requests, i.e. as SIP PUBLISH requests.Publication requests, therefore may comprise a request for versioning,e.g. as “versioning required”, in addition to the usual data content D1.

In a first step 2:1, the client 200 processes a publication andinterrogates a cache in order to determine if the data content D1 of thepublication, delivered as a SIP PUBLISH request has been sent to theserver in a previous request. However, since this is the first time datacontent D1 is to be transmitted to the server 201, no data content whichis identical to D1 can be found in the cache. The SIP PUBLISH request istherefore transmitted unchanged to the server in a next step 2:2. Inresponse to the SIP PUBLISH request, the server, supporting versioning,generates and assigns a data identifier “x”, which will be used toidentify data content D1, and stores, or caches this data and theassociated data identifier “x” in a cache in a next step 2:3. Accordingto one embodiment, the data identifier may be an already existing Etag,which, in addition to its conventional use, may be used also for thedescribed versioning purpose. The SIP PUBLISH request can now beprocessed by the server 201 according to conventional procedures.

Next, the server 201 indicates a successful reception of the SIP PUBLISHrequest to the client 200, including an indication that versioning issupported has been executed by generating a response message, e.g. a 200OK. The response message comprises data identifier “x” and e.g.“versioning done”, and is transmitted to the client in a subsequent step2:4. Once the client has received the 200 OK response message, dataidentifier “x” is cached together with data content D1, as indicatedwith a next step 2:5.

At a later occasion, a new SIP PUBLISH request, comprising of presenceinformation, here denoted data content D2, is provided to the client 200by the presentity. The publication is processed by the client andinterrogated by checking the cache, and also this time it is determinedthat data content D2 has not already been published to the server bychecking the cache of the client 200. This procedure is executed at astep 2:6, prior to transmitting the request to the server 201 at a nextstep 2:7.

In a subsequent step 2:8, the server interrogates the SIP PUBLISHrequest and verifies that versioning is required and, thus, another dataidentifier “y”, associated with data content D2 is retrieved by theserver. The data identifier “y” is then cached at the server 201,together with the associated data content D2, and the SIP PUBLISHrequest can be processed by the server 201 in a conventional manner. Thesuccessfully completed reception of the SIP PUBLISH request, including asuccessful execution of the required versioning procedure, executed fordata content D2, is then verified to the client in a 200 OK responsemessage, as indicated with a step 2:9. In resemblance to step 2:5, dataidentifier “y” and data content D2 are then cached by the client 200 ina next step 2:10.

Once again the client 200 receives presence information from thepresentity. This time, however, the inserted presence information isfound to be identical to already transmitted data content, i.e. datacontent D1. Since a checking procedure at the cache reveals that datacontent D1 is already present in the clients cache, a modified SIPPUBLISH request, only comprising the data identifier associated with D1,i.e. data identifier “x”, which is retrieved from the cache, but no datacontent, will be transmitted to the server. This procedure is executedat a step 2:11, and a SIP PUBLISH request, with a reduced size, comparedto an ordinary SIP PUBLISH request will be transmitted to the server ina next step 2:12.

At a subsequent step 2:13, the server recognises that the SIP PUBLISHrequest only comprises data identifier “x”, and, thus, the cache will beinterrogated for determining whether there is data content stored whichcan be linked to via data identifier “x”. When found in the cache, datacontent D1 is added to the SIP PUBLISH request before it is processed bythe server 201 in a conventional manner. The server verifies asuccessful versioning to the client 200 by transmitting a 200 OKresponse message to the client, as illustrated with a step 2:14. If,however, the expected data content could not be found in the cache, theserver 200 will instead respond by requesting for a retransmission. Sucha retransmission will be a complete SIP PUBLISH request, comprising boththe data identifier and the relevant data content, which upon receptioncan be cached accordingly, before the data content is inserted into thepublication, which is forwarded to a processor for conventionalpublication processing.

As mentioned above, once presence information has been delivered to theserver 201, and if applicable, a successful versioning has beenexecuted, the retrieved data content can be further processed by theserver 201, i.e. the data content can be delivered to one or morewatchers as a notification, all according to conventional, well knownpresence service procedures.

By indicating in the requests sent to the server 201 when versioning isrequired, the suggested versioning mechanism may be enabled or disabled,respectively, upon request, thereby allowing the respective informationexchange service to disable versioning and to run the service in aconventional manner, only using versioning when required, or on a morepermanent basis. Alternatively, versioning may be enabled, e.g. betweena presence server and a watcher, while being disabled between thepresentity and the presence server, or vice versa.

According to another embodiment, an alternative versioning mechanism maybe introduced, wherein a data identifier is generated already at theclient, instead of at the server. An exemplary scenario, illustratingsuch a mechanism will now be described with reference to FIG. 3.

Initially, a SIP PUBLISH request comprising a request for versioning andpresence data, delivered as data content D1, initiated by thepresentity, is processed and checked against a cache of a client 300 ina first step 3:1, in order to determined if data content D1 has beenpreviously transmitted to a server 301. Since this is the first timedata content D1 is transmitted to server 301, no corresponding datacontent will be found in the cache. As a result, the SIP PUBLISH requestis provided with a data identifier “x”, generated at, and inserted bythe client 300. The SIP PUBLISH request is then transmitted to theserver 301 in a subsequent step 3:2.

At the server 301, it is determined that versioning is required, and thedata content D1 and data identifier “x” are therefore cached subsequentto receiving the SIP PUBLISH. This is illustrated with a step 3:3. Asuccessful reception and versioning is verified to the client with a 200OK response message, as illustrated with a step 3:4. In response to the200 OK response message, also the client caches data content D1 togetherwith data identifier “x” in a cache of the client 300, in a next step3:5.

In steps 3:6-3:10, a corresponding procedure is repeated for anothersetting of presence data, delivered as data content D2, and in acorresponding way another data identifier “y”, associated with datacontent D2 is derived and inserted into the SIP PUBLISH request,together with D2.

In another step 3:11, the client 300 receives and processes a new SIPPUBLISH request, comprising new presence data for publishing. Since achecking at the cache reveals that the new presence data, represented asdata content D1, is identical to an already transmitted, and cachedversion of presence data, i.e. the data content transmitted in step 3:2,the SIP PUBLISH request is modified, stripping the request from its datacontent and inserting data identifier “x” into the request, wherein dataidentifier “x” will be used as an identifier of data content D1 at thereceiving end, i.e. at the server 301. A SIP PUBLISH request of limitedsize will now be transmitted to the server in a next step 3:12.

At the server 301 it is checked whether the data content, identified bydata identifier “x”, has been cached previously or not. This is done ina subsequent step 3:13. Successful reception, and versioning of the SIPPUBLISH request is then indicated to the client 200 with a 200 OKresponse message, in a final step 3:14.

In resemblance to the previous embodiment, failure to find the relevantpresence data in the cache will result in a request for a retransmittedpublishing request, wherein both presence data and the associated dataidentifier will be transmitted in a SIP PUBLISH request. The presencedata can now be retrieved from the cache and added to the SIP PUBLISHrequest, which will then be available for processing, according to wellknown publishing processing procedures.

Today Presence Servers may be equipped with some sort of cachingalgorithm, such as, e.g. a Least Recently Used (LRU) algorithm, assuringthat the number of versions of data content stored in the cache does notexcess a preset limit. An LRU algorithm keeps track of, and removes theleast recently used version, whenever the limit for the maximum numberof versions that the server can handle is about to be reached.

In addition to the embodiments described above, covering pushing ofinformation from a client to a server, the described versioningmechanism, or any corresponding mechanism, may be applicable also forpolling of information.

Typically for a presence service, a watcher, subscribing for presenceinformation associated with a certain presentity, or a group ofpresentities, will be notified of a new relevant published dataidentifier as soon as it is available at the presence server. Such anotification is typically forwarded to the Watcher as a SIP NOTIFYrequest. By introducing versioning also when handling notificationsforwarded from a presence server towards a watcher, even more capacitycan be gained than what is the case when handling publications,delivered to the presence server from a presentity.

A scenario, exemplifying how a client, operating as a watcher, mayinteract with a server, operating as a presentity server, for handlingupdated presence information, using the described versioning mechanism,according to one embodiment, will now be described with reference toFIG. 4.

A client 401 wanting to subscribe to presence information of a specificpresentity (not shown) can initiate such a subscription by sending a SIPSUBSCRIBE request to a server 400, as indicated with a first step 4:1.Since the client 401 supports versioning and wants to activate thisfeature, a request, such as e.g. “versioning required” is added to theSIP SUBSCRIBE request. The server 400, also supporting versioning,responds by returning a 200 OK response message to the client 401 in asubsequent step 4:2.

Once a subscription of presence information, including versioning, hasbeen activated by the server 400, the server will notify the client 401when a change has occurred in the respective presentity's presence data.In another step 4:3, the server receives and processes a SIP NOTIFYrequest, comprising presence data for delivery to the client. Once theserver has identified new presence data, by executing conventionalpresence service processing, the data content, in this case deliveredvia a publication, will be interrogated. In this case versioning isrequired and, thus, this is indicated in a respective notification, e.g.as “versioning required”. In addition to the data content, D1, the SIPNOTIFY request is also provided with an associated data identifier,which may be the same one as was used for the publishing case, describedearlier, or it may be a new data identifier, generated by and insertedinto the SIP NOTIFY request at the server. In resemblance to theembodiments describing publication deliveries, the data identifier maybe provided into the notification, either at the server 400 or at theclient 401. In this embodiment, the data identifier is provided to thenotification at the server 400. At a step 4:4, a SIP NOTIFY request,comprising data content D1 and an associated data identifier “x”, istransmitted to the client.

Upon receiving the SIP NOTIFY request, the client 401 caches thepresence data D1 and the associated data identifier “x”, as indicatedwith a subsequent step 4:5. At this stage the retrieved presence datacan be processed by the client in a conventional manner.

The client 400 then verifies a successful reception, including asuccessful versioning, by transmitting a 200 OK response message to theserver 400 in a next step 4:6. In response to the 200 OK responsemessage, the server 400 caches data content D1 and the associated dataidentifier “x” in another step 4:7. At subsequent steps 4:8-4:12, acorresponding notification procedure is executed also for presence dataD2, which is delivered to the client 401, together with an associateddata identifier “y”. At another step 4:13, a new notification isgenerated at the server 400 in response to the reception of apublication from the presentity. A new SIP NOTIFY request, comprisingpresence data, this time identified as data content D1, is againidentified at the server 400. This time, however, it is determined thatdata content D1 has already been delivered from the server 400 to theclient 401, since an identical version of the presence data is found inthe cache. As a consequence, the SIP NOTIFY request to be delivered tothe client 401 will only comprise data identifier “x”, but no presencedata, and thus, the request will be modified, stripping the request fromits data content, D1, inserting instead data identifier “x” into therequest. A notification of reduced size is then transmitted to theclient in a subsequent step 4:14.

The client 401, receiving a SIP NOTIFY request, only comprising aversion, interrogates the cache in order to determine whether thepresence data associated with data identifier “x” actually has beencached at a previous stage. Since this was done at step 4:5, therespective presence data, i.e. data content D1, is retrieved from thecache and added to the notification. This is indicated with a step 4:15.The client 401 sends a 200 OK response message to the server 400 in asubsequent step 4:16, verifying a successful versioning, and the storeddata content D1 can now be processed by the client 401 in a conventionalway.

Alternatively, a procedure corresponding to the one described withreference to FIG. 2, wherein a data identifier is provided to the SIPNOTIFY at the client instead of at the server, may be applicable. Such amechanism may rely e.g. on using Etags.

In an alternative embodiment, a client, receiving updated informationfrom a server, may indicate to the server how many versions of datacontent it can handle. This information can be provided to the server400 in a first response message to a request. Alternatively, eachresponse messages sent by a server may comprise an indication as to howmany remaining versions the client can handle. Any of these twoalternative ways of controlling the number of versions of data content,handled simultaneously by a client and stored in the cache, may beimplemented and used as a complement to, or as an alternative to an LRUalgorithm.

Which actual value as such that is chosen to indicate a specific dataidentifier is not of relevant importance. The server may for examplechoose the same value when notifying different clients, wherein a dataidentifier could be any string that is unique for the client, such as,e.g. a hash value of the included data, or simply a data identifier thatis kept by the server and the client.

The suggested versioning mechanism requires that the entities involvedin the communication of the requests keep track of which data content,e.g. presence data, that has been transmitted to which entity.

As described above, this may be achieved by caching the data content andan associated data identifier both at the transmitting, and thereceiving entity.

FIG. 5 schematically illustrates how such a caching mechanism may beorganised, according to one embodiment. The figure illustrates howcaching may be arranged for one presentity 500 and two watchers 501,502,all of which are adapted to enable versioning according to any of theembodiments, described above. The clients 500-502 may access differentinformation exchange services from a presence server 503, also adaptedto enable versioning. It is to be understood that in the figureadditional functionality necessary for execution of relevant services atthe respective entities have been omitted for simplicity reasons.

The presentity 500 comprises a cache 504 for caching data content and anassociated data identifier that has been successfully transmitted by thepresentity 500 to the server 503. A subsection used for caching whentransmitting publications to server 503 is represented by 505. At thewatchers 501 and 502, subsections of caches 505 and 506 are representedby 507 and 508, respectively. A watcher receiving a notification fromthe server 503 caches the received presence data, together with therespective data identifier, and interrogates the cache when anotification, only comprising a data identifier is received in order toretrieve the respective data content. The server comprises one cache 509for caching incoming requests, i.e. for caching presence data contentand a data identifier associated with publications received from aclient. The server also comprises one cache 510 for caching outgoingrequests, i.e. for caching presence data content and a data identifierassociated with notifications transmitted to a terminating client. Asubsection 511 of cache 509, is used for storing information receivedfrom presentity 500, while cache 510 has corresponding subsections 512and 513, where presence data and a data identifier associated withWatcher 501 or 502, respectively, are stored.

Exemplary embodiments describing functionality for executing aversioning mechanism according to any of the described embodiments at aserver and clients will now be described with reference to FIG. 6-8. Itis to be understood that the arrangements described in the followingsections are purely logical and that the described units, providingrelevant functionality at the nodes, can be implemented in different,alternative ways. It is also to be understood that any functionalitywhich is not necessary for the understanding of the mechanism behind theimplementation of the proposed versioning feature have been omitted forsimplicity reasons.

FIG. 6 describes a client 600, e.g. a presentity, which is adapted todeliver data content, e.g. presence information, to a server (notshown), e.g. a presence server, according to one embodiment. The client600, comprises a conventional processing unit 601, typically along withadditional processing units, adapted to process requests, associatedwith a requested information exchange service.

Before a request, which may require versioning, is forwarded to therelevant server via a conventional communication unit 602, it isinterrogated by a versioning unit 603, while a request not requiringversioning will be handled according to known procedures, i.e. forwardeddirectly to the communication unit 602, which then forwards the requestto the respective server in a conventional manner. The versioning unit603 is connected to a cache 604, where a complete version of datacontent and an associated data identifier are stored the first time thedata content is transmitted to the server. According to one embodiment,the versioning unit is also adapted to provide a data identifier, whichwill be associated with a respective data content. According to anotherembodiment, where a data identifier is instead provided by the server,the versioning unit is adapted to cache the data content in response toreceiving a response message, i.e. a 200 OK response, verifying asuccessful reception of a request, including the successful execution ofa versioning procedure.

In order to enable versioning at a server, also the server has to beadapted accordingly. A server, such as e.g. a presence server, adaptedto provide versioning according to any of the embodiments describedabove will therefore now be presented with reference to FIG. 7.

The Server 700 of FIG. 7 comprises at least one conventionalcommunication unit 701 for communicating with clients (not shown), suchas, e.g. presentities, providing service related data content viarequests forwarded as messages, e.g. publications, to the server. Theserver is also adapted to communicate with watchers, which may expectanother type of messages, e.g. notifications, to be delivered from theserver, according to predefined rules and constraints. The communicationunit 701 is adapted to forward a message, e.g. a publication, receivedfrom a client, to a versioning unit 702. If no versioning is requestedin the massage, the message is forwarded directly to a conventionalprocessing unit 703, where it can be processed in a conventional manner.In response to receiving a publication, one or more notifications maye.g. be generated, all according to relevant subscriptions, managed bythe server 700. In case versioning is supported by the server 700, areceived message comprising a request for versioning, but no dataidentifier, will be provided with a data identifier, which is added tothe message and forwarded to the initiating client.

In case a data identifier is instead provided at the client, a message,comprising a request for versioning and the data identifier togetherwith the associated data content will instead be identified by theversioning unit 802. The data content and the data identifier are thencached at a first cache 704, dedicated for the receiving side of theserver, prior to processing the message at the processing unit 703, anddelivering an associated message, e.g. notification, to thecommunication unit 701. In case versioning is required and a dataidentifier is present, but no associated data, i.e. this data contenthas been delivered to the server before, the versioning unit 702, isinstead adapted to interrogate the first cache 704 to determine, whetherthe data content associated with the data identifier is actually storedin the first cache 704.

A message to be delivered to a client from the server, e.g. as anotification, is provided to the versioning unit 702 from the processingunit 703. The message, comprising a request for versioning, a dataidentifier, and associated data content will be checked by theversioning unit 702, which is interrogating a second cache 705,dedicated for the transmitting end of the server 700. If data contentlinked to by the respective data identifier is found in the second cache705, this means that the present data content has been transmitted tothe respective client before. The versioning unit then modifies themessage by removing the data content, in order to limit the size of themessage. If, however, no corresponding data content can be found in thesecond cache 705, it is determined that this is the first time the datacontent is to be transmitted to the client and, thus, the message willremain unchanged, carrying both data content and a version whentransmitted to a terminating client.

The data content and the corresponding data identifier are thenforwarded to the communication unit 701, from where the notification istransmitted to a respective client, and in response to receiving a 200OK response message from the client, indicating a successful receptionand versioning of the message, the data content and the associated dataidentifier are cached at cache 705.

If it is found by the versioning unit that versioning of the publicationis required, but no versioning has been executed in a prior step, e.g.during publishing, or if separate versioning procedures is to beexecuted at the different server ends, the versioning unit is adapted toprovide the message with a data identifier before delivering the messageto the client. If a terminating client responds with a negative responseto such a message, which was carrying a data identifier but no datacontent, the versioning unit 702 is adapted to generate a new message,comprising both the new data identifier and the relevant data content,retrieved from the cache 705. The versioning unit 702 then forwards thenew message to the communication unit 702 for transmission to theclient.

A client, such as e.g. a Watcher, adapted to enable versioning forreceived messages, e.g. notifications from a Server has already beenmentioned above. Such a modified client will now be described withreference to FIG. 8. A message delivered by a server (not shown), suchas e.g. the one described above, is received by a communication unit801, of a client 800 and interrogated by a versioning unit 802. Uponreceiving a message, comprising a request for versioning, but no dataidentifier, the versioning unit 802 is adapted to provide a dataidentifier, such as e.g. an Etag, which is then cached at a cache 803,together with the associated data content. The versioning unit 802 isalso adapted to provide a response message comprising the dataidentifier to the server.

If, however, the message comprises a data identifier, but no datacontent, the versioning unit 803 is adapted to instead check the cache803 for data content stored together with the respective dataidentifier, and to provide the message with the respective identifieddata content, before the message is forwarded to the processing unit 804for conventional processing of the message. A message comprising a dataidentifier and associated data content is handled accordingly by theversioning unit 802, and the data identifier and the associated datacontent are stored at the cache 803 in response to a successfulreception and versioning of the message. Upon having cached thedelivered content, the message is forwarded to the processing unit 804for processing of the data content.

Nodes involved in data processing according to any of the embodimentsdescribed above may be configured to use any of the described versioningmechanisms, or a corresponding solution, as an alternative to standardfunctionality, i.e. when required according to circumstances, orparallel to standard transmission functionality.

While the invention has been described with reference to specificexemplary embodiments, the description is generally only intended toillustrate the inventive concept and should not be taken as limiting thescope of the invention, which is defined by the appended claims.

1. A method in a communication network of delivering messages associatedwith an information exchange service between a first entity and a secondentity, said method comprising the following steps, executed by thefirst entity: processing a message associated with an informationexchange service, said message comprising data content and a request forversioning, wherein versioning comprises associating each version ofdata content of a message with a data identifier, identifying saidversion, determining if the data content has already been delivered tothe second entity, and transmitting said message unchanged to the secondentity in case said data content has not already been delivered to thesecond entity, or transmitting a modified message to the second entityin case the data content has already been delivered to the secondentity, said modified message comprising a data identifier but no datacontent.
 2. A method according to claim 1, wherein said first entity isa server and said second entity is a client.
 3. A method according toclaim 2, wherein said message is a SIP notification.
 4. A methodaccording to claim 3, further comprising the following step, to beexecuted prior to said processing step: receiving a request for aninformation exchange service from the second entity, said requestindicating that versioning is required.
 5. A method according to claim1, wherein said first entity is a client and said second entity is aserver.
 6. A method according to claim 5, wherein said message is a SIPpublication.
 7. A method according to claim 1, wherein said determiningstep comprises interrogating a cache.
 8. A method according to claim 1,wherein said data identifier is inserted into said message at the firstentity.
 9. A method according to claim 1, wherein said data identifieris provided from the second entity.
 10. A method according to claim 9,wherein said data identifier is provided to the first entity in aresponse message, said response message indicating successful deliveryof said message.
 11. A method in a communication network of handlingmessages associated with an information exchange service at a firstentity, wherein said messages are delivered from a second entity to saidfirst entity, said method comprising the following steps: receiving amessage associated with the requested information exchange service, saidmessage comprising a request for versioning, wherein versioningcomprises associating each version of data content of a message with adata identifier, identifying said version, determining if said messagecomprises data content, retrieving a data identifier associated with thedata content and storing said data content together with said dataidentifier, in case said message comprises data content, or providingthe message with stored data content, associated with a data identifier,said data identifier being retrieved from the message, in case saidmessage does not comprise any data content, and processing the message.12. A method according to claim 11, wherein said first entity is aclient and said second entity is a server.
 13. A method according toclaim 12, wherein said message is a SIP notification.
 14. A methodaccording to claim 13, further comprising the following step, to beexecuted prior to said receiving step: forwarding a request for aninformation exchange service to the second entity, said requestindicating that versioning is required.
 15. A method according to claim11, wherein said first entity is a server and said second entity is aclient.
 16. A method according to claim 15, wherein said message is aSIP publication.
 17. A method according to claim 11, wherein saidretrieving step comprises retrieving said data identifier from the firstentity.
 18. A method according to claim 17, wherein said data identifieris forwarded from the first entity to the second entity in a responsemessage, said response message indicating a successful delivery of saidmessage.
 19. A method according to claim 11, wherein said retrievingstep comprises retrieving the data identifier from the message, saiddata identifier being inserted into said message at the second entity.20. A method according to claim 1, claims, wherein said data content andsaid associated data identifier are stored in a cache of said firstentity subsequent to receiving a response message, verifying that saidmessage has been successfully delivered to and stored at a cache of saidsecond entity.
 21. A method according to claim 20, wherein a firstresponse message comprises an indication of the total capacity of thecache of said second entity.
 22. A method according to claim 20, whereineach response message comprises an indication of the remaining capacityof the cache of said second entity.
 23. A method according to claim 1,wherein said data identifier is a version number or a unique identity.24. A method according to claim 1, wherein said data identifier is anEtag.
 25. A first entity of delivering messages associated with aninformation exchange service to a second entity, said first entitycomprising: a processing unit for processing a message associated withthe requested information exchange service, said message comprising datacontent and a request for versioning, wherein versioning comprisesassociating each version of data content of a message with a dataidentifier, identifying said version, a versioning unit for determiningif the data content has already been delivered to the client, and acommunication unit for transmitting the message unchanged to the clientin case said data content has not already been delivered to said client,or for transmitting a modified message to the client in case said datacontent has already been delivered to said client, said modified messagecomprising a data identifier but no data content.
 26. A first entityaccording to claim 25, wherein said first entity is a server and saidsecond entity is a client.
 27. A first entity according to claim 26,wherein said communication unit further comprises: a receiver forreceiving a request for an information exchange service from the secondentity, said request indicating that versioning is required.
 28. A firstentity according to claim 26, wherein said versioning unit is adapted tointerrogate a cache in order to determine if said data content hasalready been delivered to said first entity.
 29. A first entityaccording to claim 25, wherein said first entity is a client and saidsecond entity is a server.
 30. A first entity of handling messagesassociated with an information exchange service, wherein said messagesare received from a second entity, said method comprising the followingsteps: a communication unit for receiving a message from the secondentity, said message comprising a request for versioning, whereinversioning comprises associating each version of data content of amessage with a data identifier, identifying said version, a versioningunit for determining if said message comprises data content, saidversioning unit being adapted to retrieve a data identifier associatedwith the data content and to cache said data content together with saiddata identifier, in case said message comprises data content, or toprovide the message with stored data content associated with a dataidentifier, after having retrieved said data identifier from themessage, in case said message does not comprise any data content, and aprocessing unit for processing the message.
 31. A first entity accordingto claim 30, wherein said versioning unit is connected to a cache, saidversioning unit being adapted to cache data content and an associateddata identifier in response to a successfully delivered or receivedmessage.
 32. A first entity according to claim 30, wherein said firstentity is a server and said second entity is a client.
 33. A firstentity according to claim 30, wherein said first entity is a client andsaid second entity is a server.